How ST 2110 Changes Software Functionality Planning

In SMPTE ST 2110 environments, custom software may form part of the operational control plane itself rather than merely supporting hardware operation. Therefore, a Software Functionality Document should define not only user-facing software behavior, but also orchestration responsibilities, NMOS interactions, control authority boundaries, redundancy logic, monitoring expectations, API dependencies, and operational failure modes. In many IP-based facilities, this document becomes as critical to system behavior as traditional wiring and signal-flow documentation.

ST 2110 changes this planning step dramatically because software is no longer just a “support utility” sitting beside the hardware. In many 2110 systems, the software is the operational nervous system.

In SDI plants:

• Hardware paths were often physically deterministic
• Routers largely “were the system”
• Software frequently enhanced workflows

In a 2110 facility:

• Software increasingly defines discovery
• Connection management
• Resource orchestration
• Timing behavior
• Monitoring
• User permissions
• Redundancy behavior
• Multiviewer composition
• Stream routing logic

In a 2110 facility, the Software Functionality Document often becomes as important as the physical wiring diagrams once were.

How 2110 Changes the Scope

The original wording implies:

“custom software may operate certain client equipment.”

In 2110 environments, software may instead:

• Define the entire control plane
• Mediate all source/destination relationships
• Maintain system state
• Determine failover behavior
• Interface with NMOS registries/orchestrators
• Bridge multiple vendor ecosystems

New Categories the Document Must Address

A traditional software functionality document might discuss:

• GUI behavior
• Control panels
• Device macros

A 2110-aware document must additionally define:

1) NMOS Behavior

• IS-04 discovery
• IS-05 connection management
• Registry relationships
• Authority ownership

Questions:

• Who owns connections?
• What happens if two controllers issue commands?
• What happens during registry failure?

2) Control-Plane vs Data-Plane Relationships

The document should explicitly state:

• What software controls flows
• What continues operating if orchestration fails
• Which operations are “hitless”
• What is locally autonomous

This is a huge new issue in 2110.

3) Redundancy Logic

Not just:

“There are two switches.”

But:

• What software decides failover?
• What happens during split-brain?
• How are A/B paths validated?
• What is automatic vs operator-driven?

4) Timing Dependencies

Software may depend on:

• PTP lock state
• Timing thresholds
• Clock quality metrics

Those dependencies should be documented.

5) API Dependencies

Modern 2110 systems often rely on:

• REST APIs
• JSON messaging
• Vendor SDKs
• Database systems
• Authentication layers

The document should define:

• API expectations
• Failure behavior
• Version dependencies

6) Monitoring and Telemetry

In SDI:

Signal presence was often enough.

In 2110: software may need to:

• Subscribe to telemetry
• Evaluate packet health
• Monitor multicast joins
• Correlate NMOS state

Those behaviors should be documented contractually.

The Biggest Conceptual Shift

In SDI:

The router defined reality.

In 2110:

The orchestration layer increasingly defines reality.

That means the Software Functionality Document becomes:

• Partly engineering specification
• Partly operational contract
• Partly systems-integration governance document